✨ Fiche d'Aide à la Décision

FAD

-

DOCUMENT D’ANALYSE FONCTIONNEL

-

FUNCTIONAL ANALYSIS DOCUMENT

Processus Achat

Microsoft Business Central

• 1. ANAL

Sommaire

1. Introduction 3

2. Vue d‘ensemble 4

3. Planification 5

4. Traitement d‘une livraison directe 6

5. Saisie d’une demande de prix 7

6. Saisie d’une commande cadre 8

7. Saisie d’une commande d‘achat 10

8. Saisie d’un retour d’une commande achat 12

9. Rapports achat 13

10. Historique achat 14

11. Annexe 1 : Liste d‘écarts 16

1. Introduction

Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :

• Visiter les sites clients comme les usines, entrepôts et/ou bureaux
• Conduire des ateliers orientés processus.
• Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
• Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
• Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
• Identifier les volumes des référentiels et données transactionnelles
• Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
• Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.

Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :

Versions du document

Liste de diffusion

1. Vue d‘ensemble
   1. Schéma d’ensemble des processus achat

Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :

3 Planification

3.1. Contexte et Hypothèses

**3.1. Contexte et Hypothèses**

Le processus d'achat du client est basé sur trois types d'achats : projets, achats génériques société et achats mutualisés multi-projet. Les besoins projets sont anticipés ou constatés et sont achetés au niveau de chaque projet. Le contrôle et la réception de la livraison sont effectués par le chef de projet, avec possibilité d'ouverture de NC (Non Conformité) et traitement de la NC avec le fournisseur.

La chaîne d'approbation est basée sur un seuil dépendant de la personne qui passe la commande ou du risque sur la commande. Les critères d'approbation incluent l'achat dans le budget ou pas.

Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, l'intégration des coûts de transport lié à la commande et la prise en compte des différents plannings (fournisseur, transport, etc.).

Les lieux de stockage sont Payerne et les fournisseurs sont organisés par spécialité. Le numéro de projet est obligatoire sur le devis pour lier la commande au projet. La documentation à joindre à la demande de devis inclut les champs Due Date et Requested Receipt Date.

Le processus de réception inclut la quantité, le rattachement à la commande et le contrôle qualité. La création d'un document de contrôle qualité inclut le rattachement de photos, le tracking lot et série, et la validation par le responsable qualité.

**Hypothèses**

* Les besoins projets sont anticipés ou constatés.
* Les fournisseurs sont organisés par spécialité.
* Le numéro de projet est obligatoire sur le devis pour lier la commande au projet.
* La documentation à joindre à la demande de devis inclut les champs Due Date et Requested Receipt Date.
* Le processus de réception inclut la quantité, le rattachement à la commande et le contrôle qualité.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

3.2. Schéma des processus ERP : Planification 1.0

3.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "fichier article" doit contenir les informations suivantes : description, référence, unité de mesure, et catégorie d'article.
- Les "demandes d'achat" doivent être créées pour chaque projet, avec un "numéro de projet" obligatoire.
- Les "devis" doivent être liés à la "demande d'achat" et contiennent les informations suivantes : date de livraison, méthode de transport, et numéro de projet.
- Les "commandes" doivent être créées à partir des "devis" et contiennent les informations suivantes : quantité, rattachement à la commande, et numéro de projet.
- Le "contrôle qualité" doit être effectué avant de marquer la pièce "réceptionnée" et doit contenir les informations suivantes : photos, tracking lot et série, et validation du responsable qualité.
- Les "lignes budget" doivent contenir les champs pour remonter le coût budgété ou le montant réel dans la commande.
- Les "dates de planification" doivent être renseignées dans les "lignes projet".
- Le "journal des achats" doit contenir les informations suivantes : date de commande, fournisseur, et quantité.
- Le "workflow validation" doit être mis en place pour valider les étapes du processus d'achat.

3.4. Documents et statistiques

Planification des achats

Le processus de planification des achats consiste à anticiper et à gérer les besoins en matière d'approvisionnement pour les projets. Les besoins sont identifiés en fonction des composants ou des licences nécessaires pour chaque projet.

Les types d'achats sont :

* Projets : achats spécifiques pour chaque projet
* Achats génériques société : achats pour la société en général (licences, ordinateurs, etc.)
* Achats mutualisés multi-projet : achats partagés entre plusieurs projets

La chaîne d'approbation est dépendante du seuil fixé en fonction de la personne qui passe la commande ou du risque sur la commande. Le critère d'approbation est l'achat dans le budget ou pas.

Les fonctionnalités souhaitées dans le système incluent :

* Suivi de la confirmation de commande fournisseur
* Date de livraison renseignée dans le système
* Intégration des coûts de transport liés à la commande
* Gestion des certificats pour les pièces VOL
* Suivi des lead times fournisseurs
* Prise en compte des différents plannings (fournisseur, transport, etc.)

Les documents et statistiques nécessaires pour la planification des achats incluent :

* Fiche article : gestion des articles et des pièces
* Journal des achats : suivi des achats et des commandes
* Workflow validation : gestion de la chaîne d'approbation
* Tableau de bord : affichage des informations pertinentes pour l'utilisateur
* Export dans Excel : export des données pour des analyses et des rapports

La gestion des projets et des Work-Packages est également essentielle pour la planification des achats. Les dates, les quantités et les budgets doivent être pris en compte pour chaque projet.

3.5. Volume des données

[INFORMATION MANQUANTE]

3.6. Écarts critiques et interfaces

**Écarts critiques et interfaces**

Les écarts majeurs entre le processus actuel du client et les bonnes pratiques ou les exigences cibles du projet sont les suivants :

* **L'absence de document d'entrée en stock** : le chef de projet n'a pas de moyen de contrôler les livraisons et les pièces reçues.
* **L'absence de suivi des certificats** : les certificats ne sont pas gérés systématiquement pour toutes les commandes.
* **L'absence de suivi des lead times fournisseurs** : les lead times fournisseurs ne sont pas suivis.
* **L'absence de prise en compte des différents plannings** : les plannings fournisseur, transport et spécialité ne sont pas pris en compte.
* **L'absence de documentation à joindre à la demande de devis** : la documentation nécessaire pour la demande de devis n'est pas précisée.
* **L'absence de champ Due Date** : le champ Due Date n'est pas utilisé.
* **L'absence de champ Requested Receipt Date** : le champ Requested Receipt Date n'est pas utilisé.
* **L'absence de gestion des Incoterms** : les Incoterms ne sont pas gérés.
* **L'absence de champ Shipment Method Code** : le champ Shipment Method Code n'est pas utilisé.
* **L'absence de suivi des quantités** : les quantités ne sont pas suivies.
* **L'absence de rattachement à la commande** : les pièces reçues ne sont pas rattachées à la commande.

Les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés sont les suivantes :

* **Intégration avec la gestion des projets** : les commandes doivent être liées aux projets.
* **Intégration avec la gestion des fournisseurs** : les fournisseurs doivent être organisés par spécialité.
* **Intégration avec la gestion des transporteurs** : les transporteurs doivent être pris en compte.
* **Intégration avec la gestion des pièces** : les pièces doivent être suivies et rattachées à la commande.
* **Intégration avec la gestion des certificats** : les certificats doivent être gérés systématiquement pour toutes les commandes.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

4 Traitement d‘une livraison directe

4.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0

4.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

4.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

4.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

4.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

1. Saisie d’une demande de prix

5.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

• 1. Schéma des processus ERP : Demande de prix 3.0

5.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

5.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

5.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

5.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

6 Saisie d’une commande cadre

6.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0

6.3. Schéma des processus ERP : Saisie d’une commande d’achat

6.4. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

6.5. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

6.6. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

6.7. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

7 Saisie d’une commande d‘achat

7.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

7.2 Schéma des processus ERP : Saisie d’une commande d’achat

7.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

7.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

7.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

7.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

8 Saisie d’un retour d’une commande achat

8.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0

8.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

8.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

8.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

8.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

9 Rapports achat

9.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

9.2 Schéma des processus ERP : Rapport achat 8.0

9.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

9.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

9.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

9.6. Ecarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

10 Historique achat

10.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

10.2 Schéma des processus ERP : Historique achat 9.0

10.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

10.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

10.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

10.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

11 Annexe 1 : Liste d‘écarts

11.1. Liste d’écarts

La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.

Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).